home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1862 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB
  1. Path: gidora.kralizec.net.au!root
  2. From: jon@zeta.org.au
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: locking
  5. Date: 13 Jan 1996 14:26:47 GMT
  6. Organization: Kralizec Dialup Internet Sydney, +61-2-837-1183 V.32bis
  7. Message-ID: <4d8ff7$phs@gidora.kralizec.net.au>
  8. References: <4d1kl2$64c@daphne.ecmwf.int> <1996Jan12.104534.1741@ittpub>
  9. Reply-To: jon@zeta.org.au
  10. NNTP-Posting-Host: dialup08.syd1.zeta.org.au
  11. X-Newsreader: IBM NewsReader/2 v1.2.5
  12.  
  13. >
  14. >Careful here! 
  15.  
  16. Agreed!
  17.  
  18. >The question boils down to the lifetime of a temporary, in  
  19. >this case the LockObject. When is it destructed? There are differences  
  20. >between compilers currently in use: some compilers destruct the temporary  
  21. >at the end of the block in which it was created (in which case Enno's  
  22. >bracket trick will restrict the lifetime of the lock), but others may  
  23. >destruct the temporary right after the call to its operator->(), in which  
  24. >case the lock is released *before* the `bar()' member function is invoked.  
  25. >I think the draft standard says the temporary will be destructed at the  
  26. >`end of the full expression' (that is, an expression that is not part of  
  27. >some other expression), so Baudoin Raoult's trick should work, but not all  
  28. >compilers are up to date yet.
  29. >
  30.  
  31. Admittedly the standard may say something different to the ARM, but the strongest
  32. assertion the ARM makes about the lifetime of a temporary is 
  33. that it must be destroyed by the end of the scope that created it.
  34.  
  35. >All in all, it is currently impossible to rely on the lifetime of  
  36. >temporary if you want to write portable code. I would go for an explictly  
  37. >declared instance of the locking object instead - which unfortunately  
  38. >requires extra coding and/or interface replication.
  39. >
  40.  
  41. Also agreed, but I don't think it results in extra coding, as I think this example
  42. from my comp.lang.c++.moderated article shows:
  43.  
  44. I wrote:
  45. > f (lockable<foo> fooH)  // or perhaps f(lockable<foo> &fooH)
  46. > {
  47. >     lockable<foo>::guard_t guard(fooH);  // lock known by fooH acquired here
  48. >
  49. >    fooH->bar();
  50. >
  51. >    //  post condition of fooH->bar() is guaranteed here 
  52. >    // because lock has not yet been released 
  53. >
  54. >    ...
  55. >
  56. >    fooH->barbar(); // object accessed again with method pre-condition
  57. >                    // guaranteed by client
  58. >
  59. > } // lock acquired by guard is guaranteed to be released here
  60. >
  61. > lockable<foo>::guard_t is a guard type similar to LockableObject that
  62. > acquires the lock known by fooH on construction and releases it
  63. > on deletion.
  64. >
  65. > The key thing here is to separate method invocation from  
  66. > lock acquisition. If you only acquire locks around method invocations 
  67. > then you are throwing away valuable knowledge about method 
  68. > post-conditions (and hence the state of the shared object).
  69. > If you want to maintain that knowledge (and most of the time you do)
  70. > it is absolutely essential that you are explicit about the period of time
  71. > that you have exclusive access to the object.
  72.  
  73.  
  74.  
  75. jon.
  76.  
  77.